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METHOD AND APPARATUS FOR REQUESTING 
AND DISPLAYING WORKLIST DATA 
FROM REMOTELY LOCATED DEVICE 

FIELD OF THE INVENTION 
5 This invention generally relates to imaging 

systems used in medical diagnostics. In particular, 
the invention relates to the retrieval of worklist 
data from a worklist broker via a network. 

BACKGROUND OF THE INVENTION 

10 In addition to storing images internally, modern 

ultrasound imaging systems need to be able to transfer 
images to various types of remote devices via a 
communications network. To successfully transfer 
images, the relevant networking features of the 

15 ultrasound imager must be compatible with the 
networking features of the, destination remote device. 
In particular, the ultrasound imager must place the 
data to be transferred in a format which can be 
handled by the destination remote device. An attempt 

2 0 to accomplish the foregoing is the adoption of the 
DICOM (Digital Imaging and Communications in Medicine) 
standards, which specify the conformance requirements 
for the relevant networking features. The DICOM 
standards are intended for use in communicating 

2 5 medical digital images among printers, workstations, 

acquisition modules (such as an ultrasound imaging 
system) and file servers. The acquisition module is 
programmed to transfer data in a format which complies 
with the DICOM standards, while the receiving device 

3 0 is programmed to receive data which has been formatted 

in compliance with those same DICOM standards. 

DICOM involves more than digital image transfer. 
DICOM functionality includes the following Service 
Classes: archive/transfer images: store (across 
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is not limited to one role: it can be both SCU and SCP 
at different times. 

The DICOM system is designed to facilitate the 
communication of digital images of different types, 
5 e.g., X-ray, computerized tomography, magnetic 
resonance and ultrasound imaging. In an ultrasound 
imager having conventional DICOM capability, three 
local real-world activities occur: Image Send, Image 
Print and Remote Verification. Image Send and Image 

10 Print can be done in either automatic or manual mode. 
Verification of remote DICOM devices configured on the 
ultrasound imager is performed when the imager is 
powered up or when requested by the system operator. 

All DICOM activities are handled in a queued 

15 manner by application software running on a host 
computer incorporated in the imager. In one type of 
ultrasound imager, the user can select any image in 
cine memory to be sent in DICOM format via a LAN to a 
remote device having DICOM capability. The host com- 

2 0 puter of the ultrasound imaging system is programmed 

with DICOM system software which facilitates trans- 
mission of image frames from the cine memory to the 
remote DICOM device via the host computer hard disk 
and the LAN. 

25 In the conventional ultrasound imager, Image Send 

can be used in automatic or manual mode, depending on 
the user configuration. When automatic mode is con- 
figured, console keys are ; used to capture the image 
and to store it on the hard disk. The request is 

3 0 queued to a DICOM queue manager (preferably imple- 

mented in software) , which requests an association 
with the destination remote device. After the 
association with the remote device has been opened, 
the queue manager "pushes" the image to the remote 
3 5 device without user intervention. The transfer is 
done in the background while scanning or other 
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operator activities continue. In manual mode, the 
captured images are archived on the hard disk or on a 
MOD during the exam(s) . Upon completion of the 
exam(s) the images are tagged using an archive menu 
5 and queued to any of the network devices that have 
been configured on the imager. The images are sent 
sequentially in the background while scanning or other 
operator activities proceed. Image Print works much 
the same way as Image Send, in both automatic and 

10 manual modes, the only difference being that the 
destination device is a printer. 

In order to accomplish image transfer, the 
ultrasound imaging system must know the configuration 
of the destination remote device prior to attempting 

15 to communicate with that device. The configuration 
data for the destination remote device is typically 
inputted to the ultrasound imager during software 
installation by a field engineer, although the DICOM 
network can be configured at any time. When the 

20 imager receives an instruction to transmit data to a 
particular remote device from the system operator, the 
imager software converts the image data to be trans- 
ferred into the DICOM format required by the destina- 
tion remote device, based on the configuration data 

25 for that device stored in system memory. The imager 
also sends a request over the network to the destina- 
tion remote device to open an association, i.e. , to 
connect the imager to the destination remote device. 
If the remote device responds in the affirmative, the 

3 0 imager and remote device then agree on which SOP Class 
is to be used and which device will act as the server 
and which as the client. The ultrasound imager also 
selects the appropriate encoding syntax from those 
accepted by the remote device. Other communication 

3 5 parameters are also negotiated. 
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sonographer. The patient currently being examined can 
be selected from the worklist. 

Because the DICOM capability is implemented in 
software, these features of the ultrasound imaging 
5 system can be readily upgraded. One goal of such 
upgrades is to increase the efficiency of the system 
operator by making the system simpler to operate, 
e.g., by requiring fewer manipulations to activate a 
particular operation. Another goal of system upgrades 
10 is to increase the ability of the imager to connect 
rapidly, efficiently and reliably to remote devices on 
the network, i.e., to increase connectivity. 

SUMMARY OF THE INVENTION 

The present invention is a computerized imager 
15 which is programmed to send an efficient modality 
worklist query to a remotely located device, e.g., a 
worklist broker. In accordance with the preferred 

y 

embodiment of the invention, a user-interactive 
Worklist Setup menu is provided which allows the user 

2 0 to select one or more search fields and enter search 

criteria for each field. The Worklist Setup menu also 
allows the system operator to control which data in 
the retrieved worklist data will be displayed on a 
user-interactive Worklist menu. The search is 

25 initiated by clicking on a virtual representation of 
a Search key on the Worklist menu. The search results 
are received from the remote worklist broker by the 
imaging system and stored in memory. The search 
fields designated for display are displayed on the 

3 0 Worklist menu. The system user can transfer all 

information for any entry displayed on the Worklist to 
the new patient menu by simply clicking on that entry. 

The invention gives the system user the ability 
to create a local patient list on the imaging system. 
35 That local patient list can be viewed on the Worklist 
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FIG. 5 is a schematic reproducing a Worklist 
Setup display menu which the operator interacts with 
during setup of a worklist query in accordance with 
the preferred embodiment of the invention. 
5 FIG. 6 is a schematic reproducing a Worklist 

display menu which the operator interacts with to 
initiate a worklist query and later select entries 
from the retrieved worklist in accordance with the 
preferred embodiment of the invention. 

10 DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

FIG. 1 shows a conventional computerized ultra- 
sound imaging system which can be programmed to 
communicate with remote devices over a network in 
conformance with the DICOM standard. The type of 

15 imaging system depicted in FIG. 1 creates two-dimen- 
sional B-mode images of tissue in which the brightness 
of a pixel is based on the intensity of the echo 
return. The basic signal processing chain is as 
follows. 

2 0 An ultrasound transducer array 2 is activated to 

by a transmitter in a beamformer 4 to transmit an 
acoustic burst which is focused at a point along a 
scan line. The return RF signals are detected by the 
transducer elements and then dynamically focused to 
25 form a receive beam by a receiver in the beamformer 4. 
The receive beamformer output data (I/Q or RF) for 
each scan line is passed through a B-mode processing 
chain 6, which preferably includes demodulation, 
filtering, envelope detection, logarithmic compres- 

3 0 sion and edge enhancement.' 

Depending on the scan geometry, up to a few 
hundred receive vectors may be used to form a single 
acoustic image frame. To: smooth the temporal tran- 
sition from one acoustic, frame to the next, some 
3 5 acoustic frame averaging i8 may be performed before 
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scan conversion. In general, the log-compressed 
display data is converted by the scan converter 10 
into X — 7 format for video ■ display . On some systems, 
frame averaging may be performed on the X — Y data 
5 (indicated by dashed block 12) rather than the 
acoustic frames before scan conversion, and sometimes 
duplicate video frames may be inserted between 
acoustic frames in order to achieve a given video 
display frame rate. The scan-converted frames are 
10 passed to a video processor 14, which maps the video 
data using a gray-scale mapping. The gray-scaled 
image frames are then sent to a video monitor 18 for 
^ display. 

]jj System control is centered in a host computer 20, 

15 which accepts operator inputs through an operator 

H interface 2 2 and in turn controls the various sub- 

ins.- 

M systems. (In FIG. 1, only the image data transfer 

™ a paths are depicted.) The operator interface comprises 

C3 a keyboard, a trackball, a multiplicity of push- 

:5 s ! 2 0 buttons, and other input devices such as sliding and 

|]3 rotary knobs. 

During imaging, a long sequence of the most 
recent images are stored and continuously updated 
automatically in a cine memory 16. Some systems are 

2 5 designed to save the R-6 acoustic images (this data 

path is indicated by the dashed line in FIG. 1) , while 
other systems store the X-^-Y video images . The image 
loop stored in cine memory 16 can be reviewed via 
trackball control, and a section of the image loop can 

3 0 be selected for hard disk storage. 

For an ultrasound imaging system which has been 
configured with a free-hand three-dimensional imaging 
capability, the selected image sequence stored in cine 
memory 16 is transferred to the host computer 20 for 
3 5 three-dimensional reconstruction. The result is 
written back into another portion of the cine memory, 
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from where it is sent to - the display system 18 via 
video processor 14 . 

FIG. 2 generally depicts a simplified DICOM 
network having an ultrasound scanner 82, a worklist 
5 broker (e.g., an RIS) 84, N storage devices 86, and M 
printing devices 88, all connected to a LAN 90. It 
will be readily appreciated that this diagram 
represents a simplified example of a DICOM network and 
that an actual DICOM network in the real world will 
10 have many more devices connected to the LAN, including 
modalities other than ultrasound imaging systems. The 
present invention is incorporated in an ultrasound 
l ;% imager (scanner) having the built-in capability to 

fjj communicate with any one or more of the devices 84, 86 

15 and 88 in conformance with the DICOM requirements. 
q A portion of such an ultrasound imager is 

w3 generally depicted in FIG. 3. At the outset it should 

be appreciated that all of the blocks depicted in FIG. 
|!3 3, with the exception of the display screen 18 and the 

"I" 20 operator interface 22, are preferably incorporated in 

IB the host computer (depicted in FIG. 1 as block 20) . 

^ It should be further appreciated that blocks 24, 28, 

3 0 and 3 2 in FIG. 3 are preferably implemented as 
software. 

25 In accordance with the preferred embodiments of 

the invention, commands inputted via the operator 
interface 2 2 are detected and processed by a control 
platform 24. In return, ■ the control platform will 
provide signals to the : > operator interface which 

3 0 activate various visual indicators on the operator 
interface to indicate the status of various functions. 
In response to manipulation of the appropriate key or 
appropriate set of keys by the operator, a worklist 
manager 28 will display operator-interactive menus, 

3 5 such as the Worklist Setupi and Worklist menus (shown 
in FIGS. 5 and 6, respectively) on the display monitor 
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18 . Each menu includes fields for data entry and 
settable fields which can be set to a desired state by 
highlighting that field using a trackball and then 
pressing the Set key on the operator interface. 
5 The operator inputs to the Worklist Setup and 

Worklist menus are received by worklist manager 28 via 
the control platform 24, When the operator initiates 
a search, the control platform 2 4 sends a Worklist 
Query" posting to the appropriate DICOM task 30, i.e., 

10 the DICOM task configured to perform modality worklist 
queries. The worklist DICOM task 30 then requests the 
worklist setup data from the worklist manager 28. The 
worklist DICOM task 3 0 constructs a worklist query in 
the format required by the destination worklist broker 

15 (e.g., 84 in FIG. 2) and then sends that worklist 
query to the network via the network manager 3 2 and 
port 34, accompanied by a destination address. 

In response to initiation of a modality worklist 
query, the DICOM task will open a connection (associ- 

20 ation) to the destination worklist broker and nego- 
tiate a syntax. In particular, the DICOM task 30 
sends a request via the network manager 32 and a port 
44 that an association with the configured worklist 
broker be opened. If the worklist broker responds 

25 affirmatively and if a communications syntax is agreed 
upon, the association is opened. Once the association 
is open and assuming that a : channel on the network is 
available (i.e., the network is not busy), the 
worklist query is sent from the imager onto the 

3 0 network via the network manager 3 2 and the port 34. 
If the destination worklist broker sends back the 
requested worklist information, then the DICOM task 3 0 
passes that information on to the worklist manager 28, 
which in turn stores it on the hard disk 2 6 and 

35 displays the information on the Worklist menu. 
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A worklist query is typically made by the system 
operator prior to initiation of an examination. One 
purpose of such a query is to retrieve patient 
information from a central location and annex that 
5 information to each image frozen and stored on the 
hard disk (26 in FIG. 3) . In accordance with the 
preferred embodiment of the invention, the system user 
configures the system to request only selected 
worklist information from the central location. 
10 Referring to FIG. 4, the system operator sets up the 
worklist (step 36) and defines the search parameters 
by interacting with the Worklist Setup menu shown in 
™ FIG. 5. After the worklist has been set up and the 

\'i search parameters defined, the operator initiates a 

□ 15 search by clicking on a Search field 74 on the 

5=5 Worklist menu (shown in FIG. 6) , which is retrieved 

C3 via a New Patient menu (not shown) . [As used herein, 

w the term "clicking" includes, but is not limited to 

p highlighting a field by manipulation of a trackball 

f[ 2 0 and then pressing a Set key on the operator inter- 

im face.] The DICOM task 30 (see FIG. 3) then opens up 

U3 an association with the RIS or other worklist broker 

(step 38) and sends the; worklist query over the 

r 

network (step 40) . The imager subsequently receives 
25 the requested worklist information from the remote 
worklist broker (step 42). If the transfer of 
worklist information from i;the remote worklist broker 
to the imaging system was successful, the association 
is then closed (step 44) . -The operator can then click 
3 0 on a particular entry in the worklist displayed on the 
Worklist menu, in response to which all retrieved 
information for that worklist entry is automatically 
entered into a new patient data file (step 46) . The 
new patient data can be viewed by returning to the New 
3 5 Patient menu on the display screen. When the user 
exits the New Patient menu,; ; a DICOM Study Instance UID 
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is created. This Study Instance UID forms the base of 
the SOP Instance UID which tells the receiving DICOM 
printer or storage device (SCP) that the image 
received belongs to a particular patient. Every image 
5 taken by the user, after ' exiting the "New Patient" 
menu, will have the same UID. 

The examination may then begin. The user will 
scan the patient (step 48), as needed. The user, at 
any time, can freeze the image (step 50) and take a 

10 snapshot of that image to send to a storage device 
(step 52) . The SOP Instance UID will direct the image 
to the proper patient's folder of images. Storage 
devices receive images one at a time. The typical 
method of image transfer to a storage device is as 

15 follows: the queue manager opens an association 
(connection) with the receiving storage device; 
transfer negotiations occur; the image is transferred; 
and the association is closed. Alternatively, the 
system can be configured to open the association once 

2 0 and keep it open throughout the entire exam. In this 
case, the association is opened upon the sending of 
the first image. Now, all images selected to be sent 
after the association has been opened, and before the 
"End Exam" button is pushed, will be transferred 

25 during that one association. No other associations 
need to be made, thereby increasing transfer 
efficiency. 1 

Referring again to FIG. 4, in response to each 
depression of a Print/ Store button configured to the 

30 destination storage device, the DICOM task associated 
with that storage device (which task is different than 
the worklist DICOM task depicted in FIG. 3) will 
determine if the association with that storage device 
is open (step 54) . If not, the storage DICOM task 

35 will open the association (step 56) , as previously 
described. If the association is already open, then 
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the storage DICOM task will attempt to send the DICOM 
object to the storage device. If the network is busy 
and the DICOM object cannot be sent, the DICOM object 
will remain queued and succeeding images will also be 
5 queued during this time, ' If the network will allow 
the DICOM object to be sent to the destination storage 
device, then the DICOM object constructed by the DICOM 
task will be transmitted to the storage device via the 
DICOM network (step 58) . The queue manager then 

10 determines whether the "End Exam" button has been 
pressed (step 60) . If it has, the queue manager 
instructs all open DICOM tasks to close any associa- 
tions (step 62). If the "End Exam" button has not 
been depressed, the association will not be closed, 

15 and the system operator can again scan the patient 
after unfreezing the image (step 61) . 

Although FIG. 3 depicts only one DICOM task, in 
accordance with the preferred embodiment of the 
invention, the imager is- programmed with multiple 

2 0 DICOM tasks. In the preferred embodiment, one DICOM 

task (32 in FIG. 3) is dedicated to sending worklist 
queries and ten DICOM tasks can be configured to 
convert image files into either print or storage 
objects. 

25 In accordance with the preferred embodiment, the 

host computer of the imager is programmed to store in 
memory configuration data input via a Device Configur- 
ation menu (not shown) for the remote worklist broker 
to be queried. Although the system can store config- 

3 0 uration data for multiple worklist brokers, the system 

is programmed so that only one configured worklist 
broker at a time can be activated. When a particular 
worklist broker is activated (e.g. , by clicking on an 
activation field on the corresponding page of the 
35 Device Configuration menu) > the DICOM task 30 (FIG. 3) 
is configured in accordance with the configuration 

5. 
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data for that particular wbrklist broker. 

In accordance with the preferred embodiment of 
the invention, a user-interactive Worklist Setup menu 
(shown in FIG. 5) is provided which allows the user to 
5 select one or more search fields and enter search 
criteria for each field. The Worklist Setup menu also 
allows the system operator to control which data in 
the retrieved worklist data will be displayed on a 
user-interactive Worklist menu. 
10 Referring to FIG. 5, the Worklist Setup menu 

comprises a list of search fields. The first column 
64 on this page comprises a toggle field for each 
™ search field. When the user highlights a toggle field 

Q using the trackball and presses the Set key on the 

|3 15 keyboard, the user may toggle through three states. 

Those states are Ignore, Display and Search (only two 
133 of which are represented FIG. 5) . The Ignore state 

■ Ba? means that the associated search field should be 

p ignored as a query. If the Ignore state is selected, 

•4 s 2 0 the trackball will take the user to the next line. 

PJ . i 

|r= The Display state defines the associated search field 

*S as "search and display" when submitting a query. If 

the Display state is selected, the trackball will take 
the user to the Display Order column 66, so that the 

25 user may choose the order in which this item will 
appear on the Worklist menu. The Search state defines 
the associated search field as "search", but do not 
display, when submitting a query. If the Search state 
is selected, the trackball will take the user to the 

30 corresponding Criteria field 68 to define that 
parameter of the search. ; 'In the example depicted in 
FIG. 5, the worklist query has been setup to search 
for all jobs scheduled in the time period from nine 
days before to nine days after March 10, 1999, the 

3 5 entry in the Exam Start Date field 68. In addition, 
the headings for the Worklist menu, duplicated in the 
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lower portion of the Worklist Setup menu, are dis- 
played in the order determined by the entries in the 
Display Order fields 66. 

After setting up the Worklist, the user returns 
5 to the New Patient menu and then uses an ROI Size 
button to page to the Worklist menu, which is depicted 
in FIG. 6. The Worklist menu is used to perform a 
query on the configured and activated worklist broker. 
When the Worklist menu appears on the display screen, 
10 the user may enter text in the allowable fields 70 for 
querying. For example, the user may enter a specific 
patient ID to query the remote worklist broker for any 
i job scheduled within the searched time window for the 

; patient identified. The search is initiated by 

i 15 clicking on a virtual representation 74 of a Search 

I key. The query results will be displayed in fields 72 

I under the respective displayed headings. The query 

1 results are also sent to the worklist manager and then 

stored on the hard disk. 

j 

= 20 The displayed search fields are dynamically 

f placed onto the screen depending on what the user has 

3 defined in the Worklist Setup menu. If the user has 

5 marked the search fields to be "Search", then the 

search criteria will only appear on the Worklist Setup 

2 5 menu. If the user has marked the search fields to be 

"Display", then those search fields will appear in 
columns near the top of the Worklist menu, directly 
above query fields 7 0 for the user to enter a desired 
query. The search fields designated for display are 

30 displayed on the Worklist menu. The system user can 

i 

transfer all information for any entry displayed on 
the Worklist menu to the new patient menu by simply 
clicking on that entry. '! That information will be 
included with each image stored in image files on the 

3 5 hard disk for that job. 

: ! 

) 
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Referring to FIG. 3 ( , the search and display 
parameters entered on the Worklist Setup and Worklist 
menus via the operator interface are processed by the 
worklist manager 28. The Search parameters are passed 
5 on to the DICOM task 30, while the worklist manager 2 8 
uses the display parameters to set up the Worklist 
menu. In response to a search initiation posting from 
the control platform, the DICOM task 3 0 formulates a 
query based on the search parameters and then sends it 
10 to the network manager 32. When the search results 
are later received from the remote worklist broker via 
the network manager, the DICOM task passes those 

□ search results on to the worklist manager 28. The 
worklist manager then stores the retrieved worklist 

]oi 15 data on the hard disk 2 6 and displays on the display 

Hi screen those entries corresponding to search fields 

designated for display, each entry being placed under 

□ the column heading to which it belongs. 

While the invention; has been described with 
j» 2 0 reference to preferred embodiments, it will be 

Sy understood by those skilled in the art that various 

changes may be made and equivalents may be substituted 
for elements thereof without departing from the scope 
of the invention. Ih addition, many modifications may 
25 be made to adapt a particular situation to the 
teachings of the invention without departing from the 
essential scope thereof. Therefore, it is intended 
that the invention not be* limited to the particular 
embodiment disclosed as the best mode contemplated for 
3 0 carrying out this invention, but that the invention 
will include all embodiments falling within the scope 
of the appended claims. 




